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Abstract 


The  Navy  is  developing  a  replacement  system,  designated  as  the  P-8 
Poseidon,  for  the  aging  P-3C  Orion  fleet  of  aircraft,  expanding  the  mission  profile  to 
meet  the  requirements  for  its  Multi-mission  Maritime  Aircraft  (MMA).  The 
Incremental  acquisition  approach  leverages  the  Commercial-Off-The-Shelf  (COTS) 
concept,  using  a  modified  Boeing  737  aircraft  system.  The  concept  integrates  the 
COTS  components  with  Government-Off-The-Shelf  (GOTS)  elements,  including 
offensive  and  defensive  systems,  mission  packages,  and  Operational  Flight  Profiles 
(OFP),  as  well  as  some  newly  developed  systems.  The  COTS,  GOTS,  and  newly 
developed  systems  are  all  software-intensive  and  drive  the  need  for  an  effective 
software  support  architecture  that  necessarily  combines  commercial  and 
Governmental  entities.  This  research  analyzes  potential  system  software 
maintenance  drivers,  and  presents  advantages  and  disadvantages  for  three  differing 
software  support  management  options.  The  conclusions  reached  lead  the 
researchers  to  recommend  that  an  organic  (Navy)  software  support  management 
structure  would  be  most  advantageous. 

Keywords:  Intelligence,  Surveillance,  &Reconnaissance  (ISR);  Anti- 
Submarine  Warfare  (ASW);  Commercial-Off-The-Shelf  (COTS);  Government-Off- 
The-Shelf  (GOTS);  Aircraft;  Software;  Information  Assurance  (lA) 
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I. 


Introduction:  Background 


A.  P-8A  Poseidon  System  Overview/Introduction 

Aging  aircraft  and  the  associated  challenges  of  supporting  older  weapon 
systems  continue  to  plague  the  Department  of  Defense  with  obsolescence  issues 
and  increased  maintenance  costs.  There  are  several  acquisition  programs  underway 
to  replace  the  aging  aircraft  fleets — for  example,  the  Joint  Strike  Fighter  (JSF)  and 
procuring  additional  F/A-18’s.  Another  initiative  to  replace  an  aging  fleet  is  the  next- 
generation  Maritime  Patrol  and  Reconnaissance  (MPR)  weapon  system:  the  P-8 
Multi-mission  Maritime  Aircraft  (MMA).  The  United  States  Navy  is  replacing  the  P-3C 
Orion,  which  has  been  in  the  inventory  for  26  years, ^  with  a  commercial-derivative 
Boeing  737-800  aircraft. 

The  system  consists  of  inter-related  segments:  the  Air  Vehicle  (everything 
that  goes  airborne  in  and  on  the  aircraft)  and  P-8A  MMA  product  support  (including 
P-8A  MMA  unique  facilities,  personnel,  training,  and  support  equipment).  In  other 
words,  this  system  includes  the  Air  Vehicle  and  all  associated  equipment,  related 
unique  facilities,  materials,  software,  services,  training,  manufacturing,  disposal, 
deployment,  and  support  required  to  ensure  that  the  P-8A  MMA  System  can 
accomplish  its  intended  operational  role.  The  Tactical  Support  Center  (TSC),  while 
a  unique  support  facility  for  MPR,  is  not  included  in  the  P-8A  MMA  System.  The  P- 
8A  MMA  System  is  required  to  operate  effectively  in  the  context  of  its  external 
system  interfaces  and  environments  (DoN,  n.d.). 

The  P-8A  Poseidon  will  maintain  the  latest  capabilities  of  the  P-3C  Orion  Anti- 
Surface  Warfare  (ASuW)  Improvement  Program  (AlP) — including  the  Anti- 
Submarine  Warfare  Acoustic  Display  and  Control  System  upgrade  (AN/USQ-78  (V)), 
the  Block  Modification  Upgrade  (BMUP),  as  well  as  a  state-of-the-art  flight  station 
and  navigation/communication  system.  Additionally,  the  P-8A  will  incorporate  in- 


Navy  officials  said  the  average  age  of  the  196  aircraft  still  in  the  inventory  is  26  years  (CNN,  2004). 
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flight  refueling  capabilities,  yielding  extended  ranges  and  time-on-station  previously 
unavailable  in  the  P-3C  fleet  (DoN,  2007,  March). 

For  the  acquisition  strategy,  the  Navy  decided  to  pursue  a  Commercial-Off- 
the-Shelf  (COTS)  solution  to  leverage  support  of  the  system  off  the  globally 
deployed  aircraft  in  the  commercial  sector  and  to  reduce  risk  across  the  program. 
This  approach  is  in  line  with  the  most  recent  Department  of  Defense  acquisition 
guidance:  “To  achieve  the  best  possible  system  solution,  emphasis  shall  be  placed 
on  innovation  and  competition.  Existing  commercial-off-the-shelf  (COTS) 
functionality  and  solution  drawn  from  a  diversified  range  of  large  and  small  business 
shall  be  considered”  (DoD,  2008,  December  8). 

By  using  the  COTS  philosophy.  Navy  leaders  are  ensuring  there  will  be 
minimal  development  costs  for  the  airframe  and  associated  systems.  The  aircraft 
airframe  has  limited  design  changes,  and  the  parts  will  be  interchangeable  with 
commercial  fleets  and  available  from  Boeing  737  (B-737)  service  centers  throughout 
the  world.  The  supportability  issues  will  likely  not  come  from  the  hardware  on  the  P- 
8;  the  challenge  will  be  in  the  software  sustainment  and  software  upgrades  for  the 
on-board  systems  supporting  a  weapon  system  scheduled  to  be  in  the  Navy 
inventory  for  20+  years  (CNN,  2004). 

The  P-8A  program  was  initially  an  evolutionary  acquisition  program  using 
spiral  development  to  align  the  requirements  with  the  acquisition  strategy.  The 
acquisition  strategy  has  now  been  changed  to  an  Incremental  Acquisition 
approach — utilizing  enhanced  system  development  to  provide  mature  capability  to 
the  Warfighter. 

The  acquisition  strategy  details  a  method  that  partners  commercial  industry 
and  the  P-8  fleet,  with  a  goal  of  delivering  the  first  increment  of  aircraft  to  the  users 
in  the  quickest,  most  cost  efficient  manner.  During  this  first  increment  (the 
Development  Phase),  the  program  will  pursue  improvement  in  system  capabilities 
through  an  incremental  development  process  to  keep  pace  with  emerging  threats. 
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technologies  and  strategic  requirements  of  the  Navy  and  Joint  Forces  (DoN,  2007, 
March). 

B.  Acquisition  Strategy 

Based  on  the  applicable  acquisition  regulations  at  the  time,  the  P-8A  program 
used  an  Evolutionary  Acquisition  approach  (using  a  spiral  development  technique)  to 
align  the  processes  employed  for  requirements  definition,  acquisition  strategy,  and 
system  development  into  a  flexible  program  to  meet  the  strategic  vision  of  the  Navy. 

Evolutionary  Acquisition  is  defined  as: 

the  preferred  DoD  strategy  for  rapid  acquisition  of  mature  technology  for  the 
user.  An  evolutionary  approach  delivers  capability  in  increments,  recognizing, 
up  front,  the  need  for  future  capability  improvements.  The  object  is  to  balance 
the  needs  and  available  capability  with  resources,  and  to  put  capability  into 
the  hands  of  the  user  quickly.  The  success  of  the  strategy  depends  on 
consistent  and  continuous  definition  of  requirements,  and  the  maturation  of 
technologies  that  lead  to  disciplined  development  and  production  of  systems 
that  provide  increasing  capability  towards  a  materiel  concept.  (DoD,  2003, 

May  12) 

The  Evolutionary  Acquisition  approach  has  been  abandoned  by  the  DoD.  In 
fact,  the  May  2009  version  of  the  Department  of  Defense  Instruction  5000.02  [DoD! 
5000.02)  dropped  the  Evolutionary  Acquisition  approach  and  the  Spiral 
Development  technique.  Now,  the  P-8  MMA  Program  Office  is  instead  restructuring 
the  program  into  an  Incremental  Acquisition  approach.  The  primary  difference 
between  the  Evolutionary  and  the  Incremental  approaches  is  that  the  increments 
within  the  Incremental  approach  are  much  more  defined  than  each  typical  spiral  in 
the  Evolutionary  approach.  The  intent  of  the  well-defined  increments  is  to  provide 
more  predictable  schedules  and  budgets,  causing  less  friction  with  Congress  and 
high-level  decision-makers.  While  the  approach  changes,  the  overall  strategy 
remains  the  same. 

The  plan  for  the  MMA  develops  a  strategy  that  provides  a  partnership 
between  the  B-737  commercial  industry  and  the  Navy  P-8  fleet.  The  strategy  also 
focuses  on  delivering  the  aircraft  to  the  users  in  the  quickest,  most  cost-efficient 
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manner.  At  the  same  time,  the  program  will  pursue  improvements  in  system 
capabilities  through  spiral  development — permitting  the  system  to  keep  pace  with 
new  technologies,  emerging  threats  and  requirements  of  the  Navy  and  Joint  Forces 
(DoN,  2007,  March). 

The  Navy  initially  selected  spiral  development  based  on  acquisition  policy  at 
program  initiation  (DoD,  2003,  May  12).  The  revised  Operation  of  the  Defense 
Acquisition  System  (DoD,  2008,  December  8)  DoD  Instruction  has  deleted  spiral 
development  as  an  evolutionary  acquisition  approach,  identifying  only  Incremental 
as  a  means  of  achieving  rapid  acquisition  of  mature  technology.  In  fact,  the  revised 
instruction  has  established  a  Configuration  Steering  Board  (CSB).  The  DoD 
mandates: 

The  Acquisition  Executive  of  each  DoD  Component  shall  establish  and  chair 
a  CSB  with  broad  executive  membership  including  senior  representatives 
from  the  Office  of  the  USD(AT&L)  [Undersecretary  of  Defense  for  Acquisition, 
Technology,  and  Logistics]  and  the  Joint  Staff.  Additional  executive  members 
shall  include  representatives  from  the  office  of  the  chief  of  staff  of  the  Armed 
Force  concerned,  and  other  Armed  Forces  representatives  where 
appropriate,  the  military  deputy  to  the  CAE  and  the  Program  Executive  Officer 
(PEO).  (DoD,  2008,  December  8) 

This  board  was  created  by  the  DoD  in  an  attempt  to  minimize  requirements  “creep” 
and  the  spiraling  costs  of  new  weapon  systems  acquisition. 

The  CSB  shall  meet  at  least  annually  to  review  all  requirements  changes  and 
any  significant  technical  configuration  changes  for  ACAT  I  and  ACAT  1A 
programs  in  development  that  have  the  potential  to  result  in  cost  and 
schedule  impacts  to  the  program.  Such  changes  will  generally  be  rejected, 
deferring  them  to  future  blocks  or  increments.  Changes  shall  not  be  approved 
unless  funds  are  indentified  and  schedule  impacts  mitigated.  (DoD,  2008, 
December  8) 

C.  System  Support  Structure 

The  current  P-8  Support  Plan  implements  a  process  to  leverage  existing  and 
worldwide  B-737  commercial  support,  products,  and  processes  with  a  cost-effective 
Contractor  Logistics  Support  (CLS)  solution  for  total  lifecycle  support  to  the  fleet  of 
P-8s  worldwide.  In  addition,  the  Program  Management  Office  (PMO)  will  evaluate 
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and  incorporate  Performance-based  Logistics  (PBL)  concepts  into  the  P-8A 
maintenance  plan  to  reduce  weapon  systems  cost  and  improve  aircraft  readiness 
(DoN,  2007,  March). 

The  Navy  is  considering  two  options  for  software  support: 

■  Assign  the  software  configuration  items  to  a  Weapons  System  Support 
Activity  (WSSA)  to  provide  software  maintenance  under  a  Operation 
and  Maintenance,  Navy  (0&M,N)  level  of  effort  [a  contractor  or 
contractors,  in  lieu  of  a  Government  activity,  may  be  used  to  provide 
software  support  where  this  Software  Support  Requirements  Analysis 
so  justifies];  or 

■  Not  assign  the  software  configuration  items  to  a  WSSA,  and  to  treat 
software  changes  under  alternative  contracting  procedures.  (DoN, 
2007,  April) 


The  P-8  acquisition  approach  combines  the  use  of  COTS  and  Government- 
Off-The-Shelf  (GOTS)  products,  including  software  applications.  Selecting  the  most 
advantageous  software  support  organizational  and  management  structure  depends 
upon  properly  analyzing  the  P-8  system  software  architecture,  life  cycle  plan,  and 
support  organizations  and  facilities.  The  following  sections  of  this  research  analyze 
the  advantages  and  disadvantages  of  differing  software  maintenance  management 
options,  as  well  as  the  impact  of  likely  software  maintenance  drivers. 
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Problem  Statement 


This  research  analyzes  the  most  advantageous  software-support  organization 
for  the  P-8  Poseidon  ASW  Aircraft  System,  given  the  known  and  planned  system 
software  architecture  and  support  organizational  structures.  This  analysis  will 
address  the  following  research  questions: 

a.  What  are  the  typical  factors  affecting  software  maintainability  and 
support  organization? 

b.  What  is  the  planned  P-8  System  Software  Architecture,  and  how  is  that 
architecture  likely  to  impact  the  maintenance  organization  concept 
decisions? 

c.  What  type  of  software  support  organizational  structure  would  be  most 
advantageous  for  the  P-8  system? 
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Research  Methodology 


A.  Analyze  Factors  Impacting  Software  Maintainability  and 

Software  Support  Organization 

An  initial  analysis  of  the  P-8  MMA  sub-organizations  appears  to  eliminate  the 
possibility  of  either  a  purely  Organic  or  purely  CLS  support  organization  option. 
Boeing  and  other  participating  contractors  are  extremely  unlikely  to  provide  data 
rights  or  enough  access  to  source  code  for  effective  support  by  a  Navy  Organic 
software  support  activity,  even  if  that  activity  could  find,  hire,  and  retain  sufficient 
quantities  of  qualified  software  engineer  “maintainers.”  Conversely,  Navy  entities 
responsible  for  the  development  and  maintenance  of  mission  software  are  unlikely  to 
provide  highly  sensitive  or  classified  software  to  CLS  organizations  without  severe 
restrictions  that  would  be  unattractive  to  potential  CLS  contractors.  A  hybrid  of 
contractor  and  DoN  organic  support  organizations  appears  to  be  the  only  practical 
approach. 

The  leadership  and  management  of  the  hybrid  organization  will  be  analyzed 
under  the  same  three  options:  CLS,  Organic,  or  Hybrid  management. 

There  are  numerous  factors  to  be  considered  in  planning  for  the  most 
advantageous  support  management  structure  for  any  system,  including  the  P-8 
system.  This  research  will  address  the  following  factors; 

■  Support  Concept  (including  Level  of  Repair  Analysis  (LORA)) 

■  Software  Architectural  Complexity 

■  Software  Design  for  Maintainability 

■  Software  Lifecycle  Support  Plan  (including  planned  upgrades,  added 

capabilities,  and  interoperability  with  future  systems  (e.g.,  net-centric 
warfare  systems) 

■  Software  Size  (Software  Lines  of  Code  (SLOG)) 

■  Software  Safety  and  Security  Considerations 


B.  Determine  Software  Supportability  Organization  Options 

This  research  will  consider  three  basic  software-support  organizational 

structures: 

■  Organic.  All  software  maintenance  management  functions  are 
conducted  by  or  under  the  direct  control  of  the  US  Government 
(Department  of  the  Navy  (DoN)). 

■  Contracted  Logistics  Support  (CLS).  All  software  maintenance 
management  functions  are  conducted  by  organizations  under  contract 
with  the  DoN. 

■  Hybrid  Organic/CLS  Structure.  The  system  software  maintenance 
management  support  is  divided  with  some  management  conducted  by 
DoN  organic  organizations  and  other  functions  conducted  by  CLS 
organizations. 

In  addition  to  P-8  operational  concerns,  several  other  factors  will  impact  the 
software  support  organizational  concept  decisions.  The  P-8  aircraft  is  based  on  a 
Boeing  commercial  design  (B-737),  so  decision-makers  must  consider  software  data 
rights  and  issues  of  proprietary  properties.  The  P-8  is  designed  to  be  a  Multi¬ 
mission  Aircraft  (MMA) — including  Intelligence,  Surveillance,  and  Reconnaissance 
(ISR)  missions  that  will  deal  with  sensitive  and  classified  data  and  that  will  likely 
employ  classified  software  programs.  Naval  Air  Systems  Command  (NAVAIR)and 
the  Federal  Aviation  Administration  (FAA)  will  obviously  need  to  scrutinize  the  flight 
software  for  safety  of  flight  issues  and  other  Naval  operational  requirements.  As 
communicating  mission  data  is  a  primary  mission,  the  PMC  must  ensure  that  all 
DoD  Information  Assurance  (lA)  requirements,  including  the  DoD  Information 
Assurance  Certification  and  Accreditation  Process  (DoD,  2007,  November),  are  met 
and  maintained.  The  dynamic  nature  of  the  P-8  MMA  software  support 
organizations  (combined  with  the  DoD  and  FAA  overseeing  entities)  will  likely  create 
a  challenging  environment  for  the  software  support  management  team. 

C.  Analyze  P-8  Software  Architecture 

This  research  analyzes  the  planned  P-8  software  architecture  to  gain  insights 
into  the  system  design  for  maintainability.  The  analysis  will  include  the  amount  of 
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new  software  applications,  legacy  applications,  number  of  different  software 
applications,  and  the  need  for  differing  application  interoperability.  The  planned  P-8 
software  architecture  will  provide  insight  into  the  relative  advantages  or 
disadvantages  of  the  organizational  alternatives. 

D.  Analyze  Initially  Planned  P-8  Software  Support 
Organizational  Structure 

As  part  of  the  initial  program  documentation,  the  researchers  conducted  some 
analysis  to  establish  the  fundamental  system  supportability  concept.  The  system 
concept  will  provide  a  framework  and  establish  parameters  and  constraints 
impacting  software  support  organization  analyses. 

E.  Analyze  Analogous  DoD  Systems 

This  research  will  contrast  several  DoD  systems  with  similar  system  software 
architectures  to  the  P-8  for  comparative  purposes.  Systems  researched  will  include 
the  US  Air  Force  B-1  B  bomber,  the  Air  Force  KC-135,  and  Air  Force  One. 
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IV. 


Data  and  Analysis 


A.  System  Acquisition  Strategy 

The  P-8  acquisition  strategy  was  one  of  Evolutionary  Approach  using  Spiral 
Development  techniques.  This  strategy  was  designed  to  provide  the  warfighter  with 
initial  capability  as  early  as  possible,  with  additional  functions  and  capabilities  added 
as  needed.  With  such  an  approach,  there  would  necessarily  be  numerous  planned 
and  unplanned  changes  that  would  impact  the  system  software  and  Post¬ 
deployment  Software  Support  (PDSS) — including  significant  software  development 
as  well  as  sustainment  type  activities.  The  evolutionary  approach  also  indicated  that 
the  final,  objective  system  configuration  was  not  known;  thus,  current  Software  Lines 
of  Code  (SLOC)  estimates  and  final  system  software  architectural  complexity  were 
likely  to  be  underestimated. 

With  the  change  of  acquisition  approach  from  the  Evolutionary  to  Incremental, 
decision-makers  conducted  a  more  detailed  analysis  in  order  to  more  fully  define  the 
work  to  be  accomplished  in  each  increment.  This  approach  should  provide  more 
accurate  estimates  (of  both  SLOC  and  the  required  software  engineering  effort)  for 
the  development  of  each  increment,  allowing  a  better  understanding  of  the  objective 
software  size  and  structure.  In  turn,  the  PDSS  estimates  should  be  more  accurately 
estimable.  The  actual  P-8  MMA  Incremental  Approach  was  not  available  for  this 
research  effort.  Without  the  actual,  updated  data,  the  researchers  conducted  more 
generalized  analyses  based  upon  the  data  provided.  Resulting  conclusions  and 
recommendations  are  based  on  the  generalized  analysis  approach. 

The  current  Software  Support  Requirements  Analysis  does  address  computer 
source  code  for  either  commercial  or  military  unique  software  developed  in  support 
of  the  P-8  program,  addresses  access  to  contractor  developed  source  code,  and 
includes  just  one  statement  regarding  obsolescence.  Unlike  the  programs  of  the 
past,  computer  resources  hardware  obsolescence  issues  are  not  expected  to  require 
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many  accompanying  software  upgrades  due  to  the  inclusion  of  portability  layers  in 
the  architecture. 

How  does  this  “built  in”  obsolescence  affect  military  weapon  systems?  With 
software  transistor  density  doubling  every  two  years  (Moore’s  Law),  each  Program 
Office  must  ensure  that  proposed  budgets  for  its  program  reflect  accurate  costs  and 
that  the  budget  justification  documents  clearly  articulate  the  criticality  of  upgrading 
weapon  system  software.  The  Government  Accountability  Office  (GAO)  explains, 
“Unless  DOD  assesses  and  secures  its  right  for  the  use  of  technical  data  early  in  the 
weapon  systems  acquisition  process  when  it  has  the  great  leverage  to  negotiate, 
DOD  may  face  latter  challenges  in  sustaining  weapon  systems  over  their  life  cycle” 
GAO,  2005,  October). 

B.  P-8  System  Software  Architecture 

The  system  software  architecture  is  based  on  an  open-systems  approach 
with  designed  portability  layers  supporting  the  Incremental  Acquisition  strategy.  The 
starting  point  for  the  architecture  is  the  reuse  of  several  Navy-managed,  mission- 
oriented  software  applications  migrating  to  the  new  platform.  These  applications  will 
be  combined  with  existing  weapon  systems  planned  for  integration  on  the  P-8,  as 
well  as  the  Boeing  avionics  package  developed  for  the  airframe  that  has  been 
modified  for  the  anticipated  mission  flight  envelopes  envisioned  for  the  P-8.  This 
initial  architecture  is  designed  to  leverage  existing  software  applications  and  focuses 
on  adapting  those  to  meet  functional  mission  requirements  of  the  P-8.  The  P-8 
systems  and  programs  involve  at  least  four  major  contractors  (Boeing,  Raytheon, 
Northrop-Grumman,  and  Smiths)  and  their  numerous  associated  subcontractors,  as 
well  as  at  least  two  major  Navy-controlled  mission  systems.  While  many  of  these 
mission  applications  have  no  doubt  been  working  together  for  some  time,  others  will 
be  newly  integrated  into  the  P-8’s  architecture.  The  supportability  aspects  of  this 
software  architecture  are  incidental  to  the  system’s  design,  as  at  least  some  of  these 
major  software  components  have  not  been  designed  to  be  integrated  together.  This 
architectural  approach  is  likely  to  require  the  development  of  software  middleware  if 
it  is  to  allow  dissimilar  applications  to  communicate  or  share  data  and  resources; 
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however,  adding  middleware  will  increase  the  software  supportability  burden  of  the 
P-8  system.  In  addition,  this  type  of  architecture  adds  to  the  difficulty  of  maintaining 
software  because  problems  or  integration  challenges  often  happen  between 
applications  supported  by  different  organizations — thus  increasing  the  likelihood  that 
more  software  maintainers  will  be  needed  to  support  the  system  than  would  be  likely 
in  an  integrated  architecture  that  was  designed  for  supportability  and  under  the 
control  of  a  single  entity.  In  addition,  integration  of  this  entire  architecture  into  a  net- 
centric  warfighting  system  (such  as  the  Navy’s  ForceNet),  will  add  to  the  system 
software  supportability  challenges  immensely.  The  challenge  is  exacerbated  by  — 
program  managers  trying  to  maintain  all  of  the  required  Information  Assurance  (lA) 
DIACAP  certifications. 

It  is  not  clear,  from  the  documentation  provided,  how  the  P-8’s  system 
software  supportability  performance  was  planned  or  communicated  with  the 
contractors  or  Government  software  engineering  organizations.  Performance 
specifications  addressing  Maintainability,  Upgradeability,  Interoperability/Interfaces, 
Reliability,  Safety  &  Security  (MUIRS)  performance  attributes  (Naegle,  2006)  of  the 
system  software  drive  the  system  architecture  toward  a  more  supportable,  flexible 
design.  The  degree  to  which  the  MUIRS  elements  were  specified  as  performance 
attributes  in  the  original  contract  is  unknown,  but  it  is  likely  they  were  difficult  to 
attain  due  to  the  P-8  acquisition  approach  that  includes  existing  software 
applications  and  procurement  of  commercial  avionics  applications  embedded  with 
the  air  platform.  There  are  several  models  that  correlate  the  system  software 
architecture  to  expected  supportability  costs  that  may  apply  to  the  P-8  Program.  Jan 
Bosch  and  PerOlof  Bengtsson  (Bosch  &  Bengtsson,  2001)  have  developed  a 
quantitative  model  assessing  the  maintainability  aspects  (quality  attributes)  of  a 
particular  software  architecture  based  on  specified,  stakeholder-based  operational 
scenarios.  This  model  requires  scenario  development  and  recommends  the 
Software  Engineering  Institute  (SEI)-developed  Architecture  Tradeoff  Analysis 
Method  (ATAM)  (Kazman,  Klein,  &  Clements,  2000).  (The  ATAM  approach  is  taught 
and  recommended  in  NPS  software  acquisition  courses).  The  stakeholder-based 
scenarios  resulting  from  an  ATAM  analysis  would  provide  great  insight  to  the 
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operational  needs  for  supportability  attributes  and  the  planned  P-8  software 
architecture  design  effectiveness  in  meeting  those  operational  needs.  It  is  designed 
to  be  used  prior  to  the  software  architectural  design  process  to  influence  the  design 
towards  supportability  performance  attributes.  The  PMO  conducted  an  ATAM 
evaluation  on  the  P-8  MMA,  but  results  of  the  analysis  were  not  available  for  this 
research.  Because  the  ATAM  data  was  not  available,  it  is  unknown  whether  the 
architectural  tradeoffs  considered  the  supportability  aspects  of  the  alternative 
designs.  As  the  P-8  software  architecture  has  been  substantially  set,  the  Bosch  and 
Bengtsson  quantitative  approach  would  be  limited  to  gaining  a  more  accurate 
estimate  of  software  support  costs. 

Mr.  Julian  Gibbs  (Gibbs,  2001)  created  a  software  support  cost  model  titled  A 
Software  Support  Cost  Model  for  Military  Systems.  This  model  focused  on  military 
systems  in  the  United  Kingdom  (UK)  and  North  Atlantic  Treaty  Organization  (NATO) 
and  might  provide  a  simpler  approach  to  estimating  supportability  costs  compared  to 
the  Bosch  and  Bengtsson  quantitative  approach.  Mr.  Gibbs  created  a  model  by 
researching  over  120  software-intensive  systems  and  then  selecting  48  of  them  for 
detailed  analysis.  The  analysis  focused  on  research  statistics  that  had  high 
correlation  to  the  empirical  system  software  supportability  cost.  Surprisingly,  several 
factors  traditionally  used  in  predicting  software  supportability  costs  (software  size 
(SLOG),  number  of  users,  number  of  sites,  etc.)  showed  low  correlation  to  the  costs 
experienced.  The  significant  factors  were  the  system’s  military  essentiality,  the 
operational  environment,  the  age  of  the  software  used,  and  the  type  of  contract.  All 
of  these  parameters  had  a  correlation  of  0.9  or  higher  with  regard  to  software 
supportability  costs.  Data  required  for  this  analysis  was  not  available  for  this 
research;  however,  the  application  of  this  model  appears  to  require  minimal  effort 
and  might  provide  additional  insight  to  the  probable  P-8  software  support  costs. 

C.  P-8  Software  Support  Architecture 

The  P-8  is  designed  in  a  two-level  maintenance  concept  with  no  intermediate 
maintenance  support  planned  between  the  Organizational  level  and  the  Depot  level 
(an  0-to-D,  two-level  concept).  While  the  following  is  not  delineated  in  the  reference 
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documents,  the  researchers  assume  that  Organizational-level  software  maintenance 
actions  would  be  limited  (immediate  action,  problem  recording,  reboot,  etc.) — with 
nearly  all  other  software  maintenance  actions  deferred  to  the  Depot  level.  The 
controlling  organization  of  those  Depot-level  support  activities  is  the  subject  of  this 
research  and  consists  of  three  options:  Organic,  CLS,  or  Hybrid  Organic-CLS. 

Maintainability,  Upgradeability,  Interoperability,  Reliability,  and  Safety/Security 
(MUIRS)  software  support  functions  will  be  almost  exclusively  performed  at  the 
depot  level  under  this  two-level  concept.  The  P-8  MUIRS  software  analysis  will  be 
conducted  in  four  different  software  testing  facilities:  The  Mission  Systems  Software 
Development  Laboratory  (SDL),  the  Mission  Systems  Integration  Laboratory  (MSIL), 
the  Weapons  Systems  Integration  Laboratory  (WSIL),  and  the  Patuxent  River 
System  Integration  Laboratory  (PAXSIL).  The  SDL,  MSIL,  and  WSIL  are  existing 
facilities,  and  the  PAXSIL  is  a  deliverable  under  the  P-8  contract.  The  SDL  and 
MSIL  facilities  are  used  by  Navy  organic  entities  to  develop,  integrate  and  test  the 
mission  software  applications.  Once  complete,  the  Navy  provides  the  developed 
Operational  Flight  Programs  (OFPs)  to  the  WSIL  and  PAXSIL  for  integration  testing 
with  the  armament/ordnance  control  subsystems,  flight  deck,  flight  station  avionics, 
and  mission  system  avionics.  Boeing  and  other  primary  contractors  will  have  access 
to  the  WSIL  and  PAXSIL  for  testing  of  system-level  integration,  specification 
compliance  verification,  and  to  support  airworthiness  certification.  The  PAXSIL  will 
not  support  software  sustainment  development  activities,  as  it  is  a  test-only 
laboratory. 

Any  discussions  about  sustainment,  whether  hardware  or  software,  must 
address  constraints  and  compliance  imposed  by  Public  Law.  The  Limitations  on 
Performance  of  Depot  Level  Maintenance  legislation  (Section  2466,  Title  10  (JSC) — 
otherwise  known  as  the  “50/50  Rule” — stipulates  that  not  more  than  50%  of  the 
funds  made  available  in  a  fiscal  year  to  a  military  department  or  defense  agency  for 
depot-level  maintenance  and  repair  may  be  used  for  work  performed  by  private- 
sector  contractors.”  This  “50/50”  rule  includes  software  maintenance.  This  becomes 
one  of  the  drivers  in  decisions  regarding  organic  versus  contractor  sustainment;  the 
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proper  estimation  of  PDSS  costs  becomes  critical  as  cost  increases  can  rapidly 
impact  the  50/50  distribution  offending. 

While  the  0-to-D,  two-level  concept  appears  to  be  a  streamlined  approach  to 
P-8  system  support,  the  Depot-level  software  support  structure  appears  to  be  very 
cumbersome.  There  are  not  less  than  five  different  software-developing  entities, 
including  four  lead  contractors  and  organic  Navy  developers.  There  are  four 
planned  Software  Integration  Laboratories  (SILs)  with  final  integration  and  contractor 
access  planned  for  two  of  the  SILs,  one  of  which  is  designed  to  be  test-only. 
Emerging  software  problems  identified  by  the  WSIL,  PAXSIL,  or  by  the  operational 
fleet  would  necessarily  be  addressed  by  one  or  more  of  at  least  five  differing  (and 
possibly  competing)  organizations  for  resolution  and  retesting  through  one  or  more 
of  the  SILs.  Integration  or  other  software  problems  involving  two  or  more  of  the 
application  developers  requires  the  cooperation  of  both,  which  may  be  complicated 
by  issues  of  contract  language,  proprietary  rights  or — in  the  case  of  the  Navy- 
developed  applications — security  clearance  and  need-to-know  concerns. 

Regression  testing  of  reengineered  or  patched  software  components  is  likely  to  be 
significant,  and  in  the  case  of  airworthiness  or  Information  Assurance  (lA)-related 
actions,  regression  testing  will  likely  be  onerous. 

With  the  numerous  software-developing  entities  anticipated  for  the  P-8 
software  architecture,  the  personnel  support  structure  is  likely  to  be  significantly 
higher  than  with  a  similar-sized  organization  supporting  an  integrated  engineering 
architecture  with  a  unified  development  staff.  Each  of  the  five  organizations  will 
have  developers,  QA  personnel,  managers,  and  support  personnel  operating  in  at 
least  two  different  environments — one  environment  designed  to  handle  immediate 
maintenance  actions  on  the  fielded  version,  and  a  second  developing/integrating  the 
next  upgrade  increment  planned.  In  addition,  the  manning  of  four  SILs  will  likely  add 
support  personnel  to  the  requirement,  as  will  the  inclusion  of  the  planned  software 
library. 
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The  P-8  support  architecture  is  significantly  driven  by  the  planned  P-8  System 
Software  Architecture,  which  is  leveraging  existing  applications,  development 
expertise,  organizations,  and  facilities — including  SILs.  This  approach  is  likely  to 
significantly  reduce  the  development  cost  when  compared  to  newly  developed, 
wholly  engineered,  integrated  software  architecture  for  the  P-8  MMA  system. 
However,  the  software  acquisition  plan  supports  the  acquisition  and  was  not 
designed  for  maintainability.  The  cost  of  PDSS  is  likely  to  be  significant  because  of 
the  resulting  support  structures,  organizations,  and  personnel.  Each  corrective 
action,  upgraded  capability,  new  interface,  or  other  software  maintenance  action  has 
the  potential  to  be  processed  through  a  labyrinth  of  structures,  organizations, 
laboratories,  tests,  certifications,  and  management  before  being  operational  on  the 
P-8  system. 

As  explained  above,  the  contractual  structure  of  the  planned  P-8  support 
architecture  appears  to  be  complex  with  prime  contractors,  numerous 
subcontractors,  and  vendors  providing  software  products  and  services.  In  addition, 
as  system  integration  continues,  it  is  likely  that  middleware  will  be  required  creating 
the  probability  that  additional  entities  will  be  needed  to  support  the  system.  This 
situation  has  the  potential  of  creating  a  confusing  array  of  contracts  that  must  be 
managed  by  the  support  organization  selected. 

D.  Software  Size 

Software  size,  measured  in  Software  Lines  of  Code  (SLOC),  is  one  indicator 
of  expected  maintainability  costs.  The  P-8  is  currently  estimating  2.657  million 
SLOC  for  the  system  as  initially  deployed.  A  study  conducted  by  Professors  Lientz 
and  Swanson  from  UCLA  indicated  that,  on  average,  one  software  maintainer 
maintained  approximately  16,500  SLOC  per  year  (Data  processing  organizations) 
(Lientz  &  Swanson,  1980).  This  is  obviously  not  completely  applicable  to  an 
integrated  weapon  system  such  as  the  P-8  MMA,  but  may  provide  a  rough  indication 
of  the  order  of  magnitude  and  of  the  level  of  support  that  might  be  expected.  Using 
the  Lientz  and  Swanson  model  (1980),  the  P-8  would  require  161  full-time  software 
maintainers  across  all  applications.  As  the  vast  majority  would  likely  be  contractors. 
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a  conservative  estimate  of  a  burdened  annual  rate  would  be  about  $150,000  per 
maintainer.  The  annual  cost  for  161  maintainers  would  be  approximately  $24.15 
million.  As  additional  spirals  of  capability  would  likely  be  developed,  the  SLOC  count 
would  increase,  and  the  cost  would  increase  accordingly.  Given  the  P-8  software 
architecture  envisioned  and  the  associated  organizational  structures  identified 
earlier,  there  would  likely  be  more  software  support  personnel  per  16.5  KSLOC 
rather  than  less  due  to  the  complexity  of  the  system  software  architecture.  There 
are  numerous  other  predictive  models  that  may  give  more  accurate  estimates,  but 
they  would  need  to  have  more  detailed  parameters  and  data  than  were  available 
with  the  documentation  provided. 

Surprisingly,  the  UK  research  and  resulting  model  (Gibbs,  2001)  did  not 
include  the  software  size  because  the  research  indicated  that  there  was  very  low 
correlation  between  the  software  size  and  the  software  supportability  costs.  This 
lack  of  correlation  indicates  that  the  size  of  the  software  may  not  be  a  significant 
driver  of  support  costs,  or  more  likely,  that  other  factors  are  more  dominant  in  the 
supportability  cost-estimation  process.  Mr.  Gibbs’  research  did  indicate  that  the 
mission  criticality,  software  age,  complexity,  and  volatility  of  the  environment 
(planned  changes,  upgrades,  new  interoperability  requirements,  etc.)  were 
significant  drivers  of  the  supportability  costs  in  defense  systems. 

E.  P-8  Lifecycle  Management 

In  2007,  the  National  Defense  Industrial  Association  (NDIA)  listed  two  of  the 
Top  Software  Issues  impacting  software  sustainment: 

■  Software  Lifecycle  planning  and  management  by  acquirers  and 
suppliers  is  ineffective. 

■  Inadequate  attention  is  given  to  total  lifecycle  issues  for  COTS/NDI 
impacts  on  lifecycle  costs  and  risk.  (Baldwin,  2007) 

The  documents  provided  did  not  detail  the  P-8  system  lifecycle  management 
plan,  but  it  is  anticipated  that  the  P-8  will  have  a  long  life-span,  with  numerous 
planned  and  unplanned  software  updates  and  upgrades.  Planned 
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updates/upgrades  for  mission  modules,  avionics,  defensive  weapon  software, 
ForceNet  (or  other  networks)  interoperability,  and  other  major  systems  likely  have 
been  scheduled  and  planned  into  the  P-8  lifecycle.  There  will  also  be  numerous 
unplanned  update  and  upgrade  requirements  for  emerging  mission  software. 
Information  Assurance,  threat  countermeasures,  network  interoperability,  safety  of 
flight,  and  other  unforeseen  requirements.  By  combining  the  planned  and 
unplanned  software  changes,  we  can  see  there  will  be  a  continuing  need  for  a 
significant  amount  of  software  support  throughout  the  P-8  lifecycle. 

The  PMO  utilized  a  systems  engineering  approach  to  develop  a  Support 
Concept  that  employs  logistic  support  solutions  such  as  centralized  contractor 
maintenance,  performance-based  Supply  Chain  Management  (SCM),  reliability- 
improvement  incentives,  and  spiral  development  in  order  to  meet  the  requirements 
established  in  the  Performance-based  Specification  (PBS).  The  PMO  has 
implemented  or  will  implement  Government-approved  commercial  processes  that 
fulfill  the  requirements  of  Supportability  Analyses  (SA) — such  as  Failure  Modes 
Effects  and  Criticality  Analyses  (FMECA),  Reverse  Logistics  Association  (RLA),  and 
Reliability  Centered  Maintenance  (RCM) — in  the  P-8A  Maintenance  Management 
Plan  (MMP).  Utilizing  legacy  and  newly  developed  data,  the  contractor  is  required  to 
populate  and  maintain  a  Supportability  database  containing  the  maintenance, 
engineering,  and  provisioning  data  necessary  to  conduct  initial  maintenance 
planning.  Once  matured,  the  P-8  software  support  group  can  utilize  the 
Supportability  database  to  update  the  Support  Concept  as  necessary  to  meet 
Readiness  and  O&S  cost  goals. 

Interim  Contractor  Support  (ICS)  will  be  established  with  The  Boeing 
Company  CLS  services  for  maintenance,  support,  and  SCM.  The  Interim  Support 
period  will  bridge  the  gap  between  System  Development  and  Demonstration  (SDD) 
and  Navy  Support  Date  (NSD) — defined  as  Initial  Operational  Capability  (IOC)  plus 
two  years.  The  Interim  Support  contract,  or  bridge  contract,  will  provide  for  the 
establishment  of  the  initial  P-8A  Main  Operating  Bases  (MOBs)  and  Primary 
Deployment  Sites  (PDSs).  The  interim  support  period  not  only  provides  support  for 
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initial  aircraft,  but  also  system  and  support  data  required  to  facilitate  the  competition 
and  implementation  of  the  eventual  long-term  support  PBL  contract.  The  Interim 
Support  period  will  provide  a  risk-mitigation  period,  in  which  NAVAIR  will  further 
evaluate  the  support  system’s  performance  and  capability  (DoD,  2007,  March). 

F.  P-8  PDSS  Support  Management 

With  the  existing  software  applications,  organizations,  and  facilities,  it  is 
unlikely  that  the  development  and  initial  maintainability  could  be  performed  by  Navy 
Organic  organizations  or  by  a  purely  CLS  contract.  The  proprietary  software 
associated  with  the  aircraft  and  other  subsystems  would  be  too  costly  to  acquire,  if 
available  at  all.  The  classified  and  sensitive  nature  of  some  mission  modules 
severely  complicates  the  use  of  contractors  for  maintenance.  There  will  most 
probably  be  a  Navy  official  who  is  charged  with  the  PDSS  responsibilities,  but  the 
organization  that  performs  the  management  may  be  one  of  three  options.  Options 
and  advantages/disadvantages  for  the  overall  management  of  the  PDSS  effort  are 
discussed  below. 

1.  Organic  Management 

■  Advantages 

o  Organic  Management  provides  unity  of  the  software  support 
function. 

o  It  facilitates  positive  control  under  Navy  leadership. 

o  It  is  likely  to  be  the  most  cost-effective  approach  after  procuring 
access  to  contractor  software. 

o  It  focuses  on  improving  system  reliability  and  availability. 

■  Disadvantages 

o  Organic  Management  could  be  very  costly  and  difficult  to  gain 
access  to  all  contractor  software  code,  future  updates/upgrades, 
and  access  to  contractor  testing/SILs,  requiring  skillful  contract 
negotiations. 
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o  It  requires  the  establishment  of  a  robust  Navy  organic 
management  team. 

o  It  requires  leaders  to  attract  and  retain  qualified  software 
professionals  for  needed  support  activities. 

o  It  requires  leaders  to  gain  and  maintain  software  licensing 
agreements,  which  may  be  challenging. 

2.  CLS  Management 

■  Advantages 

o  CLS  Management  provides  unity  of  the  software  support 
function. 

o  The  size  of  the  effort  in  terms  of  funding  levels  is  likely  to 
incentivize  the  contractor  competition  for  CLS  contract. 

o  CLS  is  likely  to  provide  the  highest  degree  of  flexibility  as  the 
contractor  is  able  to  expand  or  contract  more  rapidly  than  the 
Government  workforce. 

o  It  maintains  the  ability  to  access  contractor  updates/upgrades 
without  separate  contract  actions. 

■  Disadvantages 

o  CLS  contract  must  be  carefully  crafted  to  ensure  that  the 
contractor’s  motivation  (money)  is  linked  with  the  Navy’s 
supportability  goals  (Reliability,  Availability,  Flexibility, 
Upgradability,  Cost-effectiveness,  etc.). 

o  Navy’s  needs  outside  of  the  scope  of  the  contract  are  likely  to 
be  very  expensive  (Unilateral  Change  Orders). 

o  CLS  contract  control  over  Navy-produced  mission  software  and 
Navy-organic  support  personnel,  SILs,  and  other  facilities  are 
likely  to  be  difficult,  especially  if  shared  with  other,  non-P-8 
program  entities. 

o  The  focus  on  profitability  may  detract  from  system  reliability  and 
availability  unless  the  contractor  is  carefully  incentivized  by  the 
contract. 

3.  Hybrid  Management 

■  Advantages 
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o  Hybrid  Management  maintains  the  chains  of  Authority  for  Navy- 
organic  and  Contractor-proprietary  software  products, 
personnel,  and  facilities  is  maintained. 

o  It  provides  the  ability  to  access  contractor  updates/upgrades. 

o  It  enhances  flexibility  by  providing  access  to  contractors  via 

support-contract  agreements. 

Disadvantages 

o  Unity  of  effort  is  lost  with  a  hybrid  approach. 

o  The  hybrid  organization  is  likely  to  have  numerous  supportability 
contracts  with  participating  contractors  and  vendors. 

o  Financial  management  is  likely  to  be  difficult  with  numerous 
organic  and  contract  funding  streams. 

o  It  is  difficult  to  manage  conflicts  between  the  various  support 
entities. 
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V. 


other  US  Defense  Systems  Software 
Supportability  Costs 


An  analysis  of  the  P-3C  Orion  system  software  supportability  costs  is 
warranted  because  the  P-8A  Poseidon  directly  replaces  the  overage  P-3  fleet; 
indeed,  most  P-3  missions  will  be  migrated  to  the  P-8.  Unfortunately,  the  P-3 
system  software  supportability  costs  were  not  available  for  this  research. 

A.  US  Air  Force  B-1  B  Bomber 

The  B-1  multi-mission  system  software  architecture  is  very  similar  to  that  of 
the  P-8.  The  B-1  software  architecture,  similar  to  the  P-8’s,  consists  of  multiple 
applications  consisting  of  both  common  military  procured  and  uniquely  developed 
software,  supported  by  three  www.opm.gov/e-qip/  organizations.  There  are 
numerous  software  vendors  and  entities  arranged  in  a  hybrid  support  organization 
and  coordinated  by  an  Air  Force  support  Program  Management  Office  (PMO).  The 
B-1  PMO  budgets  approximately  $100  million  annually  for  software  sustainment — 
including  software  repairs,  updates,  upgrades,  new  functionality,  interoperability,  and 
safety/security/information  Assurance  compliance.  At  a  time  when  the  Air  Force  is 
accomplishing  major  software  upgrades  to  the  system,  the  budget  is  $227  million  for 
2010.  (R.  Owens,  personal  communication.  May  14,  2009  and  Terri  Wells,  Feb  2, 
2010). 

B.  US  Air  Force  KC-135  Aerial  Refueling  Tanker 

The  KC-135  system  software  is  not  comparable  to  the  P-8’s  because  it  is  an 
older  system  with  one  primary  mission.  The  KC-135’s  software  consists  of 
approximately  2.6  million  software  lines  of  code  (KSLOC)  and  budgets 
approximately  $12  million  annually  for  software  support.  The  KC-135  supportability 
is  managed  through  an  organic  Air  Force  PMO  and  includes  contracted  software- 
support  arrangements.  In  planning  for  necessary  software  updates,  the  2010 
through  2014  budgets  are  rapidly  expanding  to  approximately  $140  million  annually 
(E.  Guttery,  personal  communication,  June  18,  2009). 
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C.  Air  Force  One 


Air  Force  One  has  approximately  5.75  million  SLOG  arranged  in  an 
architecture  that  is  not  similar  to  that  of  the  P-8.  Air  Force  One  is  supported  through 
a  CLS  contract  with  Boeing  Corporation.  The  annual  software  support  budget  for  Air 
Force  One  is  approximately  $5  million.  Planned  software  upgrades  will  accelerate 
the  annual  software  support  budget  to  approximately  $25  million  for  a  fleet  of  two 
aircraft  (E.  Guttery,  personal  communication,  June  18,  2009). 

By  examining  other  US  aircraft  software-supportability  costs,  it  is  clear  that 
complex  software  architectures  can  be  very  expensive  to  support  (as  demonstrated 
by  the  B1  B  bomber  above).  With  the  information  provided  by  all  three  of  the 
systems,  we  can  see  that  the  costs  to  upgrade  software  can  rapidly  inflate  the  need 
for  software  supportability  funding  in  fielded  systems. 
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VI. 


Conclusions  and  Recommendations 


A.  Conclusions 

■  This  research  clearly  indicates  that  a  hybrid  Organic/CLS  software- 
support  structure  provides  the  most  advantageous,  and  possibly  the 
only  practicable  support-organization  concept.  Proprietary  software 
associated  with  the  commercially  based  aircraft  would  be  extremely 
expensive  to  procure,  if  available  at  all — virtually  eliminating  an  all- 
Organic  support  organization.  Classified  and  sensitive  Navy-controlled 
data  and  software  programs  (combined  with  planned  use  of  legacy 
programs  currently  supported  by  organic  support  elements)  make  it 
impractical,  overly  costly,  or  impossible  to  contract  out  all  software 
maintenance  in  a  wholly  CLS  support  concept. 

■  There  does  appear  to  be  an  opportunity  to  opt  for  differing 
methodologies  for  managing  the  software  supportability  effort.  Each  of 
the  three  options  has  advantages  and  disadvantages  that  may 
influence  the  decision,  and  the  recommendation  provided  by  this 
research  was  based  on  the  degree  of  control  and  the  likely  cost  of 
managing  the  effort. 

■  The  software  supportability  cost  control  will  be  challenging.  The 
mission-critical  nature  of  the  P-8,  the  complex  structure,  software  size, 
and  the  anticipated  number  of  significant  upgrades,  changed/added 
missions.  Information  Assurance/countering  of  new  threats,  and 
eventual  networking  of  the  system  into  the  Navy’s  ForceNet  or  other 
DoD  net-centric  warfighting  structures,  indicates  that  there  will  be  the 
need  for  significant  software  updates  and  upgrades  in  the  future.  As 
illustrated  by  the  KC-135  and  Air  Force  One  programs,  software 
upgrades  can  often  rapidly  accelerate  the  need  for  supportability 
funding. 

B.  Recommendations 

While  it  is  clear  that  the  P-8  software  support  organization  must  certainly  be  a 
hybrid  of  Navy  and  contractor  entities,  the  Organic  (Navy)  support  management 
option  appears  to  provide  the  Navy  with  the  highest  degree  of  control  in  terms  of 
both  support  services  and  cost  and,  thus,  is  the  recommended  approach. 

It  is  highly  recommended  that  the  contractor  and  Navy  decision-makers 
negotiate  the  access  to  all  software  for  supportability  purposes  prior  to  any 
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contracting  actions  in  order  to  provide  the  Navy  with  the  maximum  leverage  possible 
in  gaining  supportability  access  at  the  most  economical  cost. 

With  the  Evolutionary  acquisition  approach  using  spiral  development 
processes  losing  DoD  and  Congressional  support,  a  reassessment  of  the  P-8 
program  into  a  well-defined  incremental  approach  seems  warranted.  If  possible, 
such  a  re-evaluation  may  provide  an  opportunity  for  decision-makers  to  more 
precisely  estimate  the  P-8  system  supportability  costs  for  future  budget 
considerations.  In  addition,  there  may  be  an  opportunity  for  some  system  software 
reengineering  toward  a  more  supportable  software  architecture,  reducing  the  costs 
of  future  upgrades. 
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